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Description 



INTRODUCTION 

[0001] This invention relates to a system and method for regulation of the issuance of digital 
certificates. 

BACKGROUND 

[0002] Industry is increasingly making use of digital certificates to implement electronic 
authentication of entities, which could be individuals, organisations, computers etc. Public Key 
Infiastructure [PKI], [1] is a system whereby central agencies are given the role of Certifying 
Authorities (C As) and these C As produce certificates for sub-entities. Such certificates certify 
the keys of each entity and enable entities to conmiunicate with confidence as to the authenticity 
or confidentiality of such communication. 

[0003] Often a national agency will perform the role of a central or root CA and certify sub-CAs 
which then certify end-users or even lower levels of CAs. Certificates are commonly based on 
the X509 standard [1] and this standard allows a certificate to state if the certified entity is 
authorised to certify other entities. 

[0004] Issuance of certificates by a root CA involves significant cost to provide security 
mechanisms that give confidence that firaudulent certificates are not produced. This cost is 
recovered by sales of certificates. If a certificate is for a CA that will be issuing certificates then 
the price of this CA's certificate will be related to the number of sub-certificates that will be 
produced* 

[0005] For larger corporations, the numbers of certificates can be accounted for using standard 
business reporting processes. For smaller corporations, this mechanism is not economic. 
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SUMMARY OF THE INVENTION 

[0006] The present invention describes a method whereby the issuance of certificates by a CA 
can be regulated with a security mechanism that does not require additional business processes. 

[0007] The CA is provided with a security token (trusted module) 103 containing the certifying 
key of the CA and a certificate, Cx, that authorises that CA to issue certificates for other entities 
106, typically within the organisation represented by the CA. The security token also includes 
the public key of the issuer to enable validation of certificates presented to the token. The 
security token is tamper-resistant to prevent copying of the private certifying key or tampering 
with the issuer public key or other stores within the token. 

[0008] The security token also includes a counter of the number of times that the certifying key 
is used to certify information presented to the token. The security token also includes a 
threshold count. Once the certifying counter reaches the threshold count, the certifying key 
mechanism is disabled. 

[0009] The CA can be supplied with a cryptographic ticket 102 from the controlling authority 
101 to enable further certificate issuance. This cryptographic ticket is presented to the security 
token. In the invention this is a digital certificate. The certificate, Cy, is presented by CA to the 
security token which will confirm that the certificate is valid using the stored certifying key. If 
the certificate, Cy, is valid and the certificate is newer than the existing certificate, Cx, then Cy 
will be used to replace Cx and the count of issued certificates will be cleared. The loading of the 
new certificate, Cy, thereby enables issuance of further certificates by the token. 

[001 0] An alternative to checking that Cy is newer than Cx is that the token can maintain a list of 
the identity of previously-loaded Cx. The new Cy would be checked against that list to prevent 
reload of an already-used certificate. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[001 1] FIG 1 is a block diagram illustrating the core entities and major process flows of the 
invention. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
[0012] Hie following embodiment is based on a security token 103 that is based on a smartcard 
or USB token running the MULT0S[2] operating system and with a proprietary application, AP. 
This specific embodiment concerns the case where a C A, C Aext^ wishes to authorise a small 

organisation to issue certificates for individuals within that organisation. CA^xt will be 
authorising a CA within the small organisation, CAint, to issue certificates to individuals 
associated with the organisation. 

[0013] The MULTOS application provides a standard IS07816 command/response interface 
[3,4] which implements the following commands (amongst other commands): 

[0014] LOGIN - a user or security office can present a command containing a PIN and, if valid, 
the PIN will unlock the card. If a pre-determined nimiber of invalid PINs are presented 
sequentially, the card will then ignore further commands ie will be locked. 

[0015] LOAD_KEY - this command is available when a security officer is logged-in and is 
intended for card production. This command is used by CAext to load tiie keys intended for 
CAint. These keys will then be used by CAjnt to certify (issue) other certificates. The 
LOAD^KEY operation resets the loaded certificate 'not-before' date. The LOAD__KEY 
command is also used to load the public key of CAcxt so that subsequent certificates issued by 
CAcxt can be verified. 
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[0016] LOAD_CERTIFICATE - the user or security officer must be logged-in. This comnuind 
is used during card production and over the life of the card. The certificate to be loaded 102 is 
issued by CA^xt 101 and the public key of CAext ^t is within the card is used to verify that the 
certificate is authentic. The certificate references a specified Organisation and Organisational 
Unit in the X.509 Certificate subject name, see [1], p57. The X.509 standard also specifies a 
'not-before' date, which specifies the date when the certificate becomes valid. If this date is 
older than the 'not-before' date of the existing certificate then the certificate load will fail as the 
certificate may have been used previously by the card to issue the allocated number of 
certificates and this may be an attempt to reload this certificate. 

[0017] GENERATE^CERTIFICATE - The card application is presented with the core 
certificate information of user name and email address 104. If the counter of issued certificates 
exceeds the maximum count allowed, the command will fail. Otherwise the coimter is 
incremented and the card will construct and sign a certificate using the supplied user data and the 
preset Organisation and Organisational Unit data and return the certificate as response data 105. 
The smartcard does not check the 'not-before' or 'not-after' X.509 dates prior to issuing a 
certificate, as the smartcard has no intemal clock. This check is not essential as it is possible, 
and is an expected requirement, for any recipient application to verify that the validity dates of 
certificates in a chain of certificates are valid. 

[0018] Although the invention has been described with reference to specific embodiments of the 
invention, it will be appreciated by those skilled in the art that it may be embodied in many other 
forms. 
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